LG-14196 | Set idv_consent_given_at timestamp #11164
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
🎫 Ticket
Link to the relevant ticket:
LG-14196
🛠 Summary of changes
This is the first of a two-part series; part 1 needs to be released before part 2.
Socure's API requires us to pass the time when a user consented to IdV. We currently store a boolean,
idv_consent_given
, on the user session, tracking whether they have agreed to sharing their data for IdV. This moves to storing a timestamp,idv_consent_given_at
, so that we can stop answering "When did the user consent?" with "Yes." (Pragmatically, because it's stored on the session, we know they consented very recently. But we should store the actual timestamp.)N.B. also that we are not currently sending any data to Socure in production environments; it is all feature-flagged off.
I am currently leaving the old
idv_consent_given
logic intact. We can release this and start settingidv_consent_given_at
in sessions.The second PR, after it's being set on new sessions, will replace the existing
idv_consent_given
boolean logic with checking the timestamp instead.I expanded the AgreementController test to assert that it was set correctly. The not-nil
idv_consent_given
assertion will be short-lived, but it's correct for now.